L2 Network
A L2 network (abbreviated network) is composed of L2 bridges (a.k.a., L2 switches, switches) connecting local area networks (LAN) or IEEE 802.1Q virtual LAN (VLAN) segments containing end stations. A switch forwards L2 frames (packets) among its interfaces (ports) based on L2 media access control destination address (MAC DA) carried by each packet. A switch performs address learning based on L2 MAC source address (MAC SA) carried by each packet, a procedure referred to as MAC learning or Address Learning into a so called MAC database. When a switch receives a packet with a known unicast (UC) DA (i.e., one it has previously learned as SA), it would forward the packet to the port from which it learned the address. Otherwise, when the DA is unknown unicast (has not been learned) or multi-destination (multicast, MC, or broadcast, BC) it would forward a packet copy (a.k.a., MC replica) to all the ports, an action referred to as flooding. A port may belong to multiple LANs, known as virtual LANs (VLANs), where address learning and forwarding is based on L2 address combined with VLAN indications carried by the packets.
A service provider may map the customer traffic into Provider Service VLANs (SVLANs) using VLAN stacking techniques (so called Q-in-Q encapsulation) in order to partition traffic of one customer from another.
Multipoint-to-Multipoint (MP) VPNs
A virtual private LAN service (VPLS) emulates the functionality of a LAN, making it possible to interconnect multiple remote access networks via a common service provider network, a.k.a., multipoint-to-multipoint (MP) connectivity, wherein all the access networks behave as a single LAN or VLAN. With VPLS, all these access networks would be assigned the same L2 virtual private network (VPN) identifier. This is analogous to assigning them the same SVLAN in an Ethernet-based provider network. For convenience, we will refer to both SVLAN and VPLS as MP VPNs. VPLS generally performs better than SVLANs. With VPLS, Ethernet packets arriving from the access network node (called, customer equipment, CE) are encapsulated in multi-protocol label switching (MPLS), based on which they are forwarded across the provider network towards the remote sites. Utilizing MPLS enables to build networks that excel in performance, quality of service (QoS) for service differentiation, traffic engineering (TE) for optimal utilization of network resources, high resiliency (particularly fast rerouting, FRR), and scalability.
VPLS architecture implements full mesh connectivity between the provider edge (PE) nodes that connect the customer access networks, this allows each access network to communicate with any other access network belonging to the same VPN. Each PE-PE path (a.k.a., L2 pipe) carrying VPN traffic is called a pseudo-wire (PW). A PW carries bidirectional traffic of a single VPN. When multiple VPNs are needed per physical link, each VPN should have its own PW flowing in parallel with the PWs.
Since there is a PW between any two PEs, a PE receiving a packet from PW must not forward it on another PW, or else the destination PE might receives two packet copies. This is referred to as split horizon rule.
An alternative to using Ethernet-VLAN for connecting a CE to provider's network is to classify customer traffic to specific VPN, the connection is so-called spoke pseudowire (spoke PW). With this method, known as hierarchical VPLS (H-VPLS), Ethernet packets already arrive encapsulated with MPLS headers over the connection to the provider network. Spoke PWs are not subject to the split horizon rule, i.e., a PE receiving a packet from VPLS PW can forward it on spoke PW and vice versa. H-VPLS is potentially preferred over either Ethernet or VLAN (Ethernet-VLAN) owing to its MPLS properties.
Point-to-Point (P2P) VPNs
A virtual private wire service (VPWS) emulates the functionality of a leased line, making it possible to interconnect two remote sites or CEs via an intermediate network. This service is referred to as point-to-point (P2P) VPN.
Like VPLS, a P2P VPN uses a PW to carry traffic across the service provider's network. It may also use H-VPLS to connect the sites to the service provider's PEs. The main advantage of P2P VPNs over MP VPNs is a reduction in complexity and cost of managing many connections. Unlike MP VPNs, there is no need to perform MAC address learning, because all the traffic arriving from one site should be delivered to the other site. Disabling MAC learning saves processing effort thereby boosting switch performance.
Redundancy
An important feature in packet-based applications is effective redundancy, which enables fault-tolerant and reliable networks. A particular case of interest is fault tolerant connectivity between a CE to service provider's network, wherein the CE is dual homed to the provider network PEs (sometimes, referred to as gateway PEs) via two connections in the form of Ethernet-VLAN or H-VPLS spokes, such that when one connection fails, the remaining connection serves for carrying the traffic.
One aspect of redundancy is avoiding L2 loops, where traffic traverses a PE or CE more than once. When a loop is not avoided, traffic would keep on circulating in the network and may either never arrive to its destination or be returned to the sender CE.
Objectives for Dual Homed Connectivity
The target MP VPN topology shown in FIG. 1 is composed of a full mesh interconnection among N sites, two of which are shown (site m and site n). Each site consists of a CE (say, CEm) that is dual homed to two PEs (PEm1 and PEm2). A split horizon rule is maintained, so that traffic that arrives to site n from site m, would not be relayed to another site (say, site p). For each two sites m and n, 4 bidirectional communication lines (PWs in this example) are established: (1) PEm1 to PEm2, local line (2) PEn1 to PEn2, local line (3) PEm1 to PEn1 distant line (4) PEm2 to PEn2 distant line. There are also local connections CEm to PEm1, CEm to PRm2, CEn to PEn1 and CEn to PRn2.
Note that some sites may prefer not to have redundancy (e.g., in order to save costs), at which case the PEm2 and PEn2 along with their connection would be removed.
The target P2P VPN topology shown at FIG. 2 is composed of two sites only, yet the components of these sites and their PW connectivity are the same as those of FIG. 1.
A partially redundant connectivity as shown at FIG. 3 is referred to as “3-Config”, where the CEn at site n is single or dual homed to PEn, compared to the two PEs (PEn1 and PEn2) at FIG. 1 and FIG. 2. This topology is less resilient because if PEn fails, CEn would lose connectivity with remote sites (site m). It is sometimes used because it requires less devices, connections, and PWs.
The objectives are listed below:                 (A1) Supporting the topologies of FIG. 1-FIG. 3. That is, redundant PW connections for either P2P or MP VPN, protecting against a failure of either PE or CE-PE connection while avoiding L2 loops. A failure of a PW due to defects in the provider network (e.g., fiber optics cut) need not be covered: it is the network operator's responsibility to deploy protection mechanisms (e.g. MPLS fast reroute) while designing the network.         (A2) It should be possible to concurrently use the redundant connections of the CE to PEs for carrying traffic, in order to maximize usage of connection capacity, rather than leaving some connections unused (a.k.a., standby state). Solutions where normally only one of the CE-PE connections is active while the other is inactive (a.k.a, “standby”), thereby typically providing half as much traffic capacity, are not acceptable.        
At FIG. 2, CE should be able to use load balancing over PEm1 and PEm2, and would switchover all traffic to PEm2 (PEm1) when the connection to PEm1 (PEm2) fails.                 (A3) No protocol/signaling/message exchange (hereafter, protocol) should be required between devices (PE to PE or PE to CE) to coordinate correct operation. Particularly, the PEs of FIG. 1-FIG. 3 should not need protocols to exchange information in order to coordinate active and standby PWs, i.e. which PW(s) should carry traffic and which ones should block it.         (A4) The discussion will be limited to a single point of failure per pair of sites, i.e. at any time only one CE-PE connection or a PE could fail per pair of sites, though some multi-failure scenarios may also be recoverable using same rules. However: (1) For MP VPN, a failure at one pair of sites should not prohibit recovery at another different pair of sites. At FIG. 4, where only the P-PWs are shown, after PEm1 of site pair (m,n) and PEk2 of site pair (k,p) fail, then traffic between sites m and n should be completely recovered, as well as traffic between sites k and p (2) A failure should be handled without disturbance to unrelated CEs. Particularly, when a CE-PE connection (CEm-PEm1 at FIG. 1) or PE (PEm1) fails, the CE (CEn) at any remote sites should be unaware of the failure and would continue normal operation. Further, when a PW (m1-n1 at FIG. 1) fails, any CE should be unaware of the failure and would continue normal operation. FIG. 4 illustrates an example of configuration with recoverable concurrent failures.         (A5) Recovery following a failure of a PE, or a PW, or a CE-PE connection should be automatic and fast, that is, completed in a short time (sub-second).         (A6) The solution should be realizable with PW (Ethernet-VLAN) as PE-PE (CE-PE) connection, respectively. However, non-PW realizations may also be also possible, e.g., Ethernet-VLAN for PE-PE or PW for CE-PE, where OAM between PEs could be realized using the so-called Connectivity Fault Management (CFM) per IEEE 802.1ag.        